[レポート] dbt 101（dbt入門） #dbtcoalesce

大阪オフィスの玉井です。

12月7日〜11日の間、Fishtown Analytics社がcoalesceというオンラインイベントを開催していました（SQLを触っている方はピンとくるイベント名ではないでしょうか）。

「Fishtown Analytics社って何やってる会社？」という感じですが、dbtというツールを開発しているベンダーです。dbtについては、下記をご覧ください。

今回は、その中からdbt 101 (US and AU-friendly)というセッションを受講したので、レポートを記します。

イベント概要

公式

• Coalesce 2020 online - December 7-11, 2020
  • dbt 101 (EU and US-friendly) - Coalesce 2020 online - December 7-11, 2020

概要

Coalesce is a conference for the dbt community! Most of our sessions assume you already have an understanding of dbt. If dbt is new to you, join us in this session to get up to speed. We'll go through the basics and give you all the information you need to get the most value out of this conference!

セッションレポート

自己紹介

• Carly氏
  • 2018年6月頃よりFishtown Analytics（dbtの開発元）で働いている
  • 以前はArtifact Uprising | Custom Photo Books & GiftsのBI責任者をしていた
  • ここでは全てのデータ変換をLookerのPDTで行っており、率直に言って混乱した
  • それ以前はSQL ServerやInformaticaを使ってコンサルティングをしていた
  • 「ETL、Redshift」とかググってdbtを見つけた
  • 独学でdbtを学び、9ヶ月でDWHを再構築した
  • そしてFishtown Analyticsへ…

ELTの歴史

• 10年前のデータ分析界隈で注目されていた技術
  • インフラ（計算力など）
  • ストレージ
• ETLのアーキテクチャに関する考察が多かった
  • どのように構築するか
  • どのようにスケーリングさせるか
  • どのようにストレージのコストを抑えるか
  • どのようにDWHのパフォーマンスを上げるか
• これらはデータアナリストが本当に解決したい問題ではなかった
  • しかし現実問題として取り組む必要があった
• ラルフ・キンボール博士が考案したDWHのアーキテクチャ等は、これらの問題を解決しようとするものである

• 今日、データ分析のアーキテクチャに関する技術は大幅に進化している
• Fivetran等のデータインジェストツールで「E」と「L」を自動化できる
  • 従量課金
  • スケーリングがいつでも可能
• SQLだけで処理ができるようになってきた
  • Python等に頼る部分が減ってきた

• データモデリングについては、2010年と2020年で、あまり変わっていない
• よくある構成その1：独自開発のコードとAirflow
  • 多くのクライアントがこの構成を使っている
  • 複数のデータエンジニアが必要（コスト増）
  • Pythonのスキルが必要
  • 新しいデータセットの作成に3〜4週間かかることも
  • 社内でインフラをホスティングする必要がある
• よくある構成その2：GUIでデータモデリングをやる
  • Informaticaはめちゃくちゃ高額
  • Informaticaはスキルの習得に時間がかかる
  • 「Informaticaが使える」という肩書すら存在する
  • バージョン管理や自動テストの機能は組み込まれていない

• 先程紹介した構成は、「データの民主化」という夢を台無しにしている
  • 欲しいデータがすぐに手に入らない
  • データが信頼できない
• 小さい会社やデータチームが2,3人しかいない場合、SQLのコピペで地獄の分析環境が誕生する

• dbtは2つの指針をもって、先述した問題に対処しようとしている
• dbtの指針その1：SQLさえ知っていれば誰でもデータパイプラインを開発できる
• dbtの指針その2：一流のソフトウェアエンジニアのように（データパイプラインを）開発できる
  • バージョン管理、自動テスト、ドキュメンテーション、再利用性
  • 「アナリティクスエンジニアリングの実践」
  • What is an analytics engineer?

• そもそも、（dbtは）なぜデータ変換にこだわるのか？
• 例えば、Fivetranがあれば、Snowflakeにデータを入れて、Lookerを繋げばよい
  • このプロセスの中で、データ変換は最も重要なステップ
• データ変換でやること
  • データ型のクリーニング
  • 複数のシステムのデータを統合
  • データのフィルタリング
  • 論理削除されているデータの除外
  • きれいなデータをそれぞれ結合

• コアコンセプトをまとめると、このような文となる

そもそもdbtとは？

• dbtはデータ分析エコシステムのどこに位置するのか？
• 左側にデータローダー
  • 生データをSnowflake、Redshift、BigQueryのようなDWHにロード
• 右側にデータ変換後のデータ
  • BIツールが使用するデータ
  • データサイエンスチームが使用するデータ
  • その他のサードパーティシステムと連携するためのデータ
• dbtはDWH上のオーケストレーション層に位置づけられる
  • 従来のETLはメモリ内で行われていた
  • dbtはプッシュダウンETL、データはDWH内に留まる
  • データがネットワーク上を移動しないので安全

• dbtはオープンソースである
  • 完全無料
  • ローカルにインストールして使用する
• dbt Cloud
  • フルマネージドでdbtが使えるサービス
  • ユーザー管理等の機能あり
  • 大規模企業とかに最適
  • 1人で使う分には無料

dbtのコアコンセプト

コアコンセプト1：全てのデータ変換はSQLのSELECT文で表現できる

• ビジネスロジックやSQL自体を生成するプログラムコードを書く必要がない
  • Python等のプログラミングを習得する必要がない
  • CREATE TABLE DROP TABLEとかする必要もない
• ビルドを繰り返し実行できる
  • ジョブを何度実行しても同じ結果が得られる
• テーブルやビューをマテリアライズすることができる
• 処理が全部SELECT文なので、SQLが多少わかる人であれば、誰でも処理内容を理解できる

• 左側に載っているのがdbtモデル
  • ここでいう「モデル」とは、データモデルのことではない
• dbtモデルとは…
  • テーブルのこと
  • ビューのこと
  • DBオブジェクトのこと
• このスライドのdbtモデルはシンプルなSELECT文
  • これを実行すると、右側のクエリに変換されて実行される（dbtで定義したテーブルが作成される）
  • SELECT文で作成したいテーブル等を定義できる

• 実テーブルだけでなく、ビューを作成することも可能
• Ephemeral
  • DWHに何も作成しない
  • モデルの処理としてだけ定義できる
• Incremental
  • 前回ジョブ実行時から変更があったデータだけを対象とする
  • 日付データやユニークキー等を使用して増分を判断
• オープンソースなので独自のマテリアライズを開発することも可能

コアコンセプトその2：{{ ref() }}

• dbtにおける（モデル間の）リレーションシップは全てrefで表現される
• メリット1：スキーマ名を補間できる
  • 環境間の移行が簡単になる
  • 例えば、それぞれのモデルをprod, test, dev, localといったref文で表現しておけば、テスト環境用のコードを本番環境に移行する時に、コード中のtestの部分全てをprodに置き換える作業は必要はない
• メリット2：モデル間の依存関係を明確にする（DAGのエッジを構築する）
  • スライドの例にあるように、SQLのテーブル名と同じ形で使用することができる
  • この中括弧はJinjaという言語のもの

• このスライドは簡単なDAG（有向非巡回グラフ）である
  • ordersというモデルは、base_ordersというモデルの実行に依存している
• base_ordersの実体はanalytics.dev.base_ordersというテーブル
  • ここではbase_ordersを別途dbtモデルとして定義済
  • だから、ordersでは、テーブル名をベタ書きするのではなく、{{ ref('base_orders') }}と記述する
  • こちらのモデルは、実際には、スライドの右側のクエリとして実行される
• refを使うことで、図のような依存関係を構築できる
  • 赤い線に注目

• （デモが映されました）
• 特定のモデル（orders）を選択すると、上流と下流の依存関係を見ることができる
  • このDAGはdbtが自動生成する
• これらのモデルは可能な限り並列で実行される
  • この図でいうと、order_productsができるまでは並列で各モデルが作成される
  • そもそも処理自体は接続しているDWH先で実行する

コアコンセプト3：簡単なテスト実行

• dbtはモデルやデータセットを簡単にテストできるようになっている
• 「このデータはこうあるべき」という仮定・前提をテストする
• テスト内容はyamlファイルに定義する
  • これ自体はただのテキストファイル
  • テスト実行時にSQLとしてコンパイルされる
• テスト内容の例
  • カラム（の値）が一意であるかどうか
  • NULLが含まれていないかどうか
  • 特定の値が除外されているかどうか
  • （それが）他テーブルの外部キーであるかどうか
• 外部キーのテストは非常に興味深い
  • 最近のDWHは、レガシーなDB（SQL ServerやOracleなど）のように、参照整合性が組み込まれていない場合があるため

• テストの例の紹介
• このスライドに記述されているテスト内容
  • peopleというテーブルにidというカラムがある
  • そのカラムにNULLが入ってなく、値が一意であるかどうかをテストする
  • そのままnot_null, uniqueと記述するだけ
• リレーションシップのテストも行っている
  • account_idというカラムと、accountというモデルのidを比較するテスト
  • このテストが失敗するとエラー通知するように記述している（severity）
  • このテストが失敗した場合、下流に連なるいくつかのモデルの実行を止めたいため
  • この例では、通知を行うだけで、実行全てを止めるわけではない

コアコンセプト4：ドキュメンテーション

• 聴講者の中に、自分が書いたコードに関するドキュメントを残している方はどのくらいいるか？
  • おそらく少ないと思う

• dbtは色々な情報をもとにドキュメントを自動で生成する
• 1：yamlファイルに記述されたdescription
  • モデルについての説明を記述する
  • 必要であればカラム単位の説明を記述する
  • モデル間の依存関係についての説明を記述する（DAG）
  • モデル自体のSQL文
• 2: DWHにあるinformation schema
  • 存在自体や内容についてはDWHによる
• 最近、ドキュメントに関するdbt用のPackageが出た
  • ドキュメントがちゃんと用意されていない時に通知等がいく
  • ドキュメントが生成されるようになってないと、本番環境にコードをプッシュできないようにもできる

• 実際に自動生成されたドキュメントの紹介
• description部分（内容）は、モデル開発者が手動で記述したもの
• 左側のカラムやデータ型は、information schemaから取得している
• モデルに対してどういうテストが設定されているかもわかる
• モデルがSQLにコンパイルされた時のクエリも確認できる
• 開発チームだけでなく、そのデータを使う人たちにとっても役に立つ
  • Tableauでレポートを作る人など（dbtドキュメントを見てどういうデータがあるか理解できる）
• デモサイトあり
  • dbt Docs

コアコンセプト5：マクロ

• SQLは基本的に再利用できない（仕組みとして無い）
  • モジュール化もされていない
• dbtではJinjaが書ける
  • dbtはSQLのためのプログラミング環境になる
• 例：IF文が書ける
  • 開発環境のDWHで実行する場合は少量のデータだけを対象にするクエリを発行し、本番環境で実行する場合は全データに対して処理を行うクエリを発行する…というロジックを、IF文で書ける
• マクロ
  • 関数とほとんど同じと思ってもらってよい

• 例えば、1セントを1ドルに変換する処理を記述する必要があるとする
  • これを複数人の開発者が同時にやると、それぞれ異なる方法で処理を実装する可能性がある
  • マクロでこの変換処理を共通化できる
• stg_paymentsというモデルで、上記の関数を使用している
  • この関数も、コンパイル時にSQL文になる
• 日付や時間の変換なんかもマクロで共通化できる
  • これらのマクロが使われているかどうかをプルリクのレビューで確認することもできる

まとめ

• dbtはデータ分析を高品質なものにする
  • 利用可能なデータセットが増える
  • データモデルに対するドキュメントが用意できる
  • テストでデータモデルの復元力が向上する
• ステークホルダーとの関係性も向上する
  • データアナリストが自分の手でデータモデルを作ることができる→権限が与えられたと感じる
  • データエンジニアは、もっと複雑な作業に取り組むことができる
  • 全てのデータパイプラインを心配する必要はなく、ビジネス上の問題に集中できる
• 独学用のコンテンツもある
  • dbt Learn on demand

質疑応答

データソースがどれだけ新鮮かテストすることはできるか？

• 可能
• データが一定時間より古い場合に通知を送る、といったことも可能
• （おそらくこちらを使用する？）
  • freshness | docs.getdbt.com

dbtで生成されたドキュメントの内容（カラムのdescriptionなど）を外部から取得することはできるか？

• 可能
• APIがあるのでそれを使用する

セッションをきいて

dbtの基本中の基本に関することを紹介してくれたセッションでした。

驚いたのは、Airflowを使ったデータ変換処理の構成を「古い」とバッサリ言い切っているところです。国内において、Pythonで組んだデータ処理のタスクを、Airflowでジョブとして管理する、というのは、まだまだ普通な印象があります。もちろん、dbtを開発している方が話しているので、ポジショントークな面もあるとは思うのですが、それでも「古い」と言い切っているのはすごいと思いました（感覚が日本より進んでいるのでしょう）。あと、データ変換の古いやり方のもう一つの例として「GUIでデータモデリングをやる」というのがありましたが、GUIとしか書いてないのに、話としてはひたすらInformaticaのことを言っていたのも、びっくりしまいした。